CommonJS规范加载模块是同步的,只有加载完成才能执行后面的操作 而 AMD规范是非同步加载模块 允许指定回调函数 由于nodeJS主要用于服务 端的编程,模块文件一般都存在本地硬盘 所以加载起来比较快 不用考虑非同步 的加载方式所以commonJS规范比较实用 但是如果是浏览器环境 要从服务器 加载模块 就必须采用非同步的方式 因此浏览器一般采用AMD规范
AMD规范:

define(['package/lib'], function(lib){
  function foo(){
    lib.log('hello world!');
  }

  return {
    foo: foo
  };
});  

AMD(“Asynchronous Module Definition”)规范允许输出的模块兼容CommonJS规范,这时define方法需要写成下面 这样:

define(function (require, exports, module){  
var someModule = require("someModule");  
var anotherModule = require("anotherModule");  
someModule.doTehAwesome();  
anotherModule.doMoarAwesome();  
exports.asplode = function (){      
someModule.doTehAwesome();    
anotherModule.doMoarAwesome();  
  };  
});    

CMD(“Common Module Definition”)是 SeaJS 在推广过程中对模块定义的规范化产出
CMD和AMD的区别有以下几点:

1.对于依赖的模块AMD是提前执行,CMD是延迟执行。不过RequireJS从2.0开始,也改成可以延迟执行(根据写法不同,处理方式不通过)。
2.CMD推崇依赖就近 用到才去require,AMD推崇依赖前置。
虽然 AMD也支持CMD写法,但依赖前置是官方文档的默认模块定义写法。

javascript具有自动垃圾回收机制 执行环境会管理代码执行过程中的内存
原理: 垃圾收集器会定期中出不在使用的变量 然后释放其内存

  1. 标记清除
    js中最为常见的回收方式就是标记清除算法     
    当变量进入环境时  在函数声明一个变量将这个变量标记为'进入  环境' 从逻辑上讲 永远不能释放进入环境的变量所占用的内存       
    因为只要执行留进入相应环境  就可能用到它们 当变量离开环境  时  将其标记为离开环境    
    
function test(){  
        let  aa = 'a';  //被标记 进入环境
    }
 test()  //执行完毕  aa被标记为离开环境被回收   

垃圾回收器会在运行时候给存储在内存中的所有变量加上标记
会去除环境中变量以及环境中变量引用的变量标记(闭包) 在此之后加上标记变量被视为准备删除的变量 最后 垃圾回收器完成清楚工作
到目前为止 IE,Firefox,Opera,Chrome,Safari实现的都是标记清除垃圾回收机制只不过垃圾收集时间不相同罢了

2.引用计数
function test(){
let a = {}; //a的引用计数为0
let b = a; // a的引用计数为1
let c = a ; //a的引用计数为2
let b = {} ; // a的引用计数减1

内存泄漏:
内存泄漏是指一块被分配的内存既不能使用,又不能回收,直到浏览器进程自动结束
在C++中 因为是手动管理内存,内存泄漏是经常出现的事情
在C#和Java等语言采用自动垃圾回收方法管理内存 正常使用时不会发生泄漏 浏览器也是采用自动垃圾回收方法管理内存.但由于浏览器垃圾回收方法由bug 会产生内存泄漏

内存泄漏的几种情况:

1. 当页面中元素被移除或者替换时,若元素绑定事件仍没有被移除,在IE中会做出恰当的处理  要手动移除事件不然会产生内存泄漏   
2.循环引用 (IE7/8) 
let a = document.querySelector(".aa")
let b = document.querySelector(".bb")
a.f = b
b.f = a   

上方代码a b互相引用 虽然会在垃圾收集系统识别处理 但是在IE下如果 循环引用的是DOM或者是ActiveX对象 垃圾回收系统不会发现它们之间的循环关系与其他对象是隔离并释放它们 最终它们会被保存在内存中 解决办法手动解除循环引用 a.f = null
我们知道,IE中有一部分对象并不是原生js对象。例如,其内存泄露 DOM和BOM中的对 象就是使用C++以COM对象的形式实现的,而COM对象 的垃圾回收机制采用的就是引用计数 策略。因此,即使IE的js引擎采用标记清除策略来实现,但js访问的COM对象依然是基于引用计 数策略的。换句话说,只要在IE中涉及COM对象,就会存在循环引用的问题。

3. 闭包    
  闭包会维持函数内局部变量 使其得不到释放    
4. 自动类型装箱转换  
let a = 'aaaa'
console.log(a.length)   
s本是string类型而非object 没有length属性  所以访问length  会自动创建一个临时的String 对象 封装s 这个对象一定会泄漏 解决方法  
console.log(new String(a).length)  

 5. 使用全局变量  也会导致内存 泄漏    
 6.  未清除的定时器  若定时器中的的元素被dom移除  定时器依然存在 同时定时器中的变量依然存在 不会被释放 
let someResource = getData();
    setInterval(function() {
        let node = document.getElementById('Node');
    if(node) {
    node.innerHTML = JSON.stringify(someResource));
        }
    }, 1000);    

参考 4 Types of Memory Leaks in JavaScript and How to Get Rid Of Them

BFC(Block Formating Context,块级格式化上下文)
块级格式化上下文就是页面上的一个隔离的渲染区域 容器内部的
子元素不过在布局上影响容器外的元素 反之也是如此
如何产生BFC呢? float的值不为none overflow值不为visible position 的值 为 position和fixed display的值为table-cell
table-caption inline-block的任何一个
常见的多栏布局 结合块级元素浮动 里面的元素在一个相对隔离的环境中运行
说到BFC就要谈谈别的FC的 FC全称Formating Contexts 是W3C 中 CSS2.1规范中一个概念 他是页面中一块渲染区域有一套渲染规则 决定子元素如何定位 以及其他元素的关系和相互作用
IFC(Inline Formating Contexts)直译为”内联格式化上下文”
设置为display:inline-block会在外层产生IFC 可通过text-align:center使其水平居中
GFC(GridLayout Formating Contexts,网格布局上下文)
当一个元素display设置为grid时 此元素获得一个独立渲染的区域
我们可以通过在网格容器(grid container)上定义网格定义行(grid definition rows)和网格定义列(grid definition columns)属性 各在网格项目(grid item)上定义网格行(grid row)和网格列(grid columns)为每一个网格项目(grid item)定义位置和空间。
FFC(Flex Formatting Contexts,自适应格式化上下文) display:flex和inline-flex 会生成自适应容器

cookie为持久保存客户端数据提供了方便 分担了服务器存储的负担,但还是有很多的局限性
第一: 每个特定的域名最懂生成20个cookie
IE和Opera会清理近期最少使用的cookie Firefox会随机清理cookie
cookie最大大约有4096个字节 为了兼容性 一般不能超过4095个字节
IE提供了一种存储可以持久化用户数据叫做userData 从IE5.0开始
每个数据最多128k 每个域名最多1M
cookie的优点:
具有极高的可扩展型和可用性
通过加密和安全传输技术(SSL)减少cookie被破解的可能性
可以控制cookie的生命周期
缺点
Cookie数量和长度的限制 每个域下最多只能有20条cookie 每个cookie长度不能超过4KB
具有安全性的问题 如果cookie被人拦截了 被转发 可以 获得session信息
有的用户在浏览器的禁用cookie

SVG是可伸缩矢量图形
SVG用于定义网络的基于矢量的图形
SVG使用XML格式定义图形
SVG再放大和缩小或改变尺寸其图形质量都不会发生变化
浏览器支持
IE9以上
和Canvas的区别
SVG是使用XML来描述2D图形的语言
Canvas用过JavaScript来绘制2D图形
SVG基于XML SVG没个DOM都是可用的 可以为某个元素附上事件处理器
SVG不适合游戏应用
Canvas是逐像素渲染 若位置发生变化 整个场景也需要重新绘制

CSRF(Cross-site request forgery)跨站请求伪造
攻击者盗用了你的身份 以你的名义发送恶意请求
准备求来说就是
1.登录受信任网站A,并在本地生成Cookie。
2.在不登出A的情况下,访问危险网站B。
如何防御呢
CSRF的防御可以从服务端和客户端两方面着手,防御效果是从服务端着手效果比较好,现在一般的CSRF防御也都在服务端进行。
在提交请求时服务器增加随机数在提交时进行后端验证
验证码 在表单提交时增加随机验证码即随机字符串

减少http请求 (使用sprite图 对js文件进行合并加载)
优化图片文件 减少其尺寸
压缩js css文件 有利于网络传输
服务器端使用gzip压缩方法

gzip是一个非常简单的方法 由于CSS文件和HTML文件使用了大量重复的文字 使用GZIP压缩公用字符串
减少页面和样式表70%的请求
把网页内容写的使压缩更有效
保持引号的一致性
优化CSS和JavaScript

网址后面加’/‘ 不加’/‘服务器会多一次判断过程加直接访问网站根目录下的默认文件
对图片标明高度和宽度 若浏览未找到这两个参数 则需要边下载边计算大小不仅影响速度 也影响用户体验

今天突然又翻一下关于xss漏洞的资料 xss又称css(Cross Site Scripting)跨站脚本攻击
之前只是以为xss只是用户输入过滤不当而造成 然而发现原来里面的学问这么深
xss分为三种类型:存储型xss 反射性xss dom-xss
存储型的xss 数据库中存有存在的xss攻击的数据,返回给客户端。若数据未被转义被浏览器渲染 有可能导致xss攻击
反射性xss 将用户输入存在的XSS攻击数据发送给后台 后台并未对数据进行存储 也未经过任何过滤 就有可能导致xss攻击
DOM-XSS
用户点击链接参数带有js语言 后台未对url参数进行过滤 返回给客户端 前端直接从url中获得参数
例如利用BOM对象location中的href进行正则匹配获得带有xss漏洞的脚本参数 攻击者利用这个漏洞做出无法想象的事情 xss攻击无处在 如何进行防御

xss漏洞的防御

对输入端和输出端统一进行过滤
对于前端 有一个xss过滤很好的类库 毕竟术业有专攻 传送门
后端 有一个不同的使用方式,编码方式不同,java现成的工具可以用——ESAPI,不同位置如何转义可参照ESAPI文档,传送门 比如属性值转义:

String safe = ESAPI.encoder().encodeForHTMLAttribute(
request.getParameter( “input” ) );

php简单过滤:

$safe = htmlspecialchars($this->input->get/post(“input”))

前端要做好的工作 要有良好的css设计 html标签a的href进行规范化 避免用JavaScript打开一个新的窗口 不要使用全局变量 将不可信的数据例如白名单 提交数据时进行校验 –完

第1步,查找浏览器缓存。

浏览器会检查缓存中有没有这个域名对应的解析过的IP地址,如果缓存中有,这个解析过程就将结束。浏览器 缓存域名也是有限制的,不仅浏览器缓存大小有限制,而且缓存的时间也有限制,通常情况下为几分钟到几小 时不等。这个缓存时间太长和太短都不好,如果缓存时间太长,一旦域名被解析到的IP有变化,会导致被客户端缓存的域名无法解析到变化后的IP地址,以致该域名不能正常解析,这段时间内有可能会有一部分用户无法访问网站。如果时间设置太短,会导致用户每次访问网站都要重新解析一次域名。

第2步,查找系统缓存。

如果用户的浏览器缓存中没有,浏览器会查找操作系统缓存中是否有这个域名对应的DNS解析结果。其实操作系统也会有一个域名解析的过程,在Windows中可以通过C:\Windows\System32\drivers\etc\hosts文件来设置,你可以将任何域名解析到任何能够访问的IP地址。如果你在这里指定了一个域名对应的IP地址,那么浏览器会首先使用这个IP地址。例如,我们在测试时可以将一个域名解析到一台测试服务器上,这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是因为有这种本地DNS解析的规程,所以黑客就有可能通过修改你的域名解析来把特定的域名解析到它指定的IP地址上,导致这些域名被劫持。

第3步,查找路由器缓存。

如果系统缓存中也找不到,那么查询请求就会发向路由器

第4步,查找ISP DNS 缓存。

能查询ISP DNS 缓存服务器了。在我们的网络配置中都会有”DNS服务器地址”这一项,操作系统会把这个域名发送给这里设置的DNS,也就是本地区的域名服务器,通常是提供给你接入互联网的应用提供商。这个专门的域名解析服务器性能都会很好,它们一般都会缓存域名解析结果,当然缓存时间是受域名的失效时间控制的,一般缓存空间不是影响域名失效的主要因素。大约80%的域名解析都到这里就已经完成了,所以ISP DNS主要承担了域名的解析工作。

第5步,递归搜索。

在前面都没有办法命中的DNS缓存的情况下,(1)本地 DNS服务器即将该请求转发到互联网上的根域(即一个完整域名最后面的那个点,通常省略不写)。(2)根域将所要查询域名中的顶级域(假设要查询ke.qq.com,该域名的顶级域就是com)的服务器IP地址返回到本地DNS。(3) 本地DNS根据返回的IP地址,再向顶级域(就是com域)发送请求。(4) com域服务器再将域名中的二级域(即ke.qq.com中的qq)的IP地址返回给本地DNS。(5) 本地DNS再向二级域发送请求进行查询。(6) 之后不断重复这样的过程,直到本地DNS服务器得到最终的查询结果,并返回到主机。这时候主机才能通过域名访问该网站。